1. Technical Field
The present invention relates to the field of configuring and provisioning additional computing resources, and more particularly to an improved conversion from single computer directory service to a distributed directory service.
2. Description of Related Art
X.500 directory model is a distributed collection of independent systems which cooperate to provide a logical data base of information to provide a global Directory Service. Directory information about a particular organization is maintained locally in a Directory System Agent (DSA) or directory server. This information is structured within specified standards. Adherence to these standards makes the distributed model possible. It is possible for one organization to keep information about other organizations, and it is possible for an organization to operate independently from the global model as a stand alone system. DSAs that operate within the global model have the ability to exchange information with other DSAs by means of the X*500 protocol.
DSAs that are interconnected form the Directory Information Tree (DIT). The DIT is a virtual hierarchical data structure. An X.500 pilot using QUIPU software introduced the concept of a “root” DSA which represents the world; below which “countries” are defined. Defined under the countries are “organizations”. The organizations further define “organizational units” and/or “people”.
The lightweight directory access protocol (LDAP) is a streamlined version of the x.500 directory service. It eliminates the ISO protocol stack, defining, instead, a protocol based on the IP protocol suite. LDAP also simplifies the data encoding and command set of X.500 and defines a standard API for directory access. LDAP has undergone several revisions and may be revised again. For example, some versions of LDAP incorporate various measures that improve security.
LDAP and the X.500 standard define the information model used in the directory service. All information in the directory is stored in “entries”, each of which belongs to at least one “object class”. As an example, in a white Pages application of X.500, object classes are defined as country, organization, organizational unit and person.
The object classes to which an entry belongs defines the attributes associated with a particular entry. Some attributes are mandatory others are optional. System administrators may define their own attributes and register these with regulating authorities, which will in turn make these attributes available on a large scale.
Every entry has a Relative Distinguished Name (RDN), which uniquely identifies the entry. A RDN is made up of the DIT information and the actual entry.
Deploying a distributed directory has been problematic in the past for a variety of reasons. First, the configuration of each backend server can be complicated, especially as the number of backend servers increases. This often means additional configuration file entries, replication agreements or referral objects which must be added to each backend server by the administrator.
Second, the data must be transferred from one main server or LDAP Data Interchange Format (LDIF) file to each backend server. This is often done through a proxy server or servers after the empty distributed directory servers are configured. Loading data into the empty directory is often very slow, as each entry was loaded through the proxy server one by one. Such loading failed to take advantage of the parallelism offered by the incipient distributed directory. Loading would benefit greatly if some parallel copying and loading could be done.
Thus, although a running distributed directory rapidly responds to client requests, such a distributed directory is cumbersome to migrate to from the typical single server configured directory support.